Skip to main content

Clean Architecture

All the problem for concurrency arrives from the problem with mutability. Hence immutability in highly scalable applications ensures there is no concurrency issues

Event sourcing eliminates Updates and Deletes and just focuses on Create and Read, storing all the transaction from the beginning of time.

Remember we have our unlimited storage and memory now so this is not a problem, also in cassandra there is a way to book mark the state of a application

Functional programming usually uses immutable variables

SOLID Principles

SRP - Single Responsibility Principle​

  • not the common way we think where each function has only one purpose, this is true and all
  • BUT SRP talks about each class to have on responsibility on each Actor
  • For example employee methods should not have to report to CIO, CFO, CTO. so functions involving calculate pay for example (for the CFO) versus functions that involve estimates of a project and time estimates is (for the CTO).
  • Knowing that stakeholders are indeed the causes for change we need to separate functions based on who is dependent on these functions. Like internal reporting should have different location vs actual customers who uses the application (EZYPAY)

OCP - Open closed Principle​

  • Open to extension, close to modification

Liskov Substitution Principle​

  • The ability for classes/components to be easily replaced

Interface Segregation Principle​

  • Do not make component depend on more than it needed to

Dependency Inversion Principle -DIP​

Important Notes

  • Architecture should not depend on frameworks
  • when building architecture it is imperative that any decisions for the peripherals be used can be delayed as long as possible.
    • For example, you should be able to delay which database to use or which framework to use (Spring, Rails, etc)

Screaming Architecture

  • your application should scream what it is designed to do, for example a Health Care System should scream Health Care System not Spring application
  • A good way to test this is unit testing components and business cases, you should be able to unit test your application without web application running or any connection to the database. In essence unit test should only test business cases in isolation
  • This also adheres to the fact that any framework is secondary (This include web application, as web is only I/O)
  • Business Cases/Rules should be the most reusable component of architecture hence they the most high level.
  • Do not be tempted by using entities and request/response models, they will change in time
  • Level of any components are determined by how close they are to the input and output
  • Stable Abstract Dependency Principe

Good flow: Dependency Rule.​

All data/dependency should flow one way avoiding circular cross dependency within components. !ss_clean_architecture.png

Notes​

  1. Remember Databases/Frameworks are just details and should not dictate your architecture
  2. Remember Screaming Architecture
  3. Do not pass around table/rows from db, this makes the flow from above dependent on the database
  4. Database and Frameworks and UI are details do NOT marry them
  • Like in spring it would be good to have auto wiring in just one Main class other than spreading it all throughout. Hibernate is another thing to be wary about.
  1. Endless Pendulum on Front-end: First there were Applets, goes back to server, then there were Ajax and JS, goes back to server, now we have Node
  2. Design for testability
  • Do not depend on fragile things like GUI
  1. Not everything should need to be recompiled if we need to change something

Microservice Architecture​

  • When you have to implement and change all the services in a micro service for a new feature then it is counter-intuitive isn’t?
  • Remember the case for Taxi service micro services, having need to add food delivery. If you had to change all the services, you have implemented it wrong. It has to be in away that the new feature just can be plugged-in

Static dependency tools:

NDepend, Structure101, Checkstyle

Good implementation of Good Architecture:

Web Controllers packages -> domain packages <- infrastructure packages

com.mycompany.myapp.OrdersController -> com.mycompany.myapp.domain.OrderService -> OrderServiceImpl <- Orders Interface <- JdbcRepositoryImpl